[IDEV-2572] domaintools v14.0: Address Bugbash Feedbacks - #4

Address Bugbash Feedback: enrichment expansion, suspicious flag fixes, and missing domain reporting

Please use a clear and concise title that summarizes your changes.
If this PR is related to an internal Buganizer ticket, please include its ID at the beginning.

• Added Is Suspicious column to the enrichment table so it's clear which domains
  were flagged alongside their risk category
• Fixed suspicious flagging to only use the Risk Threshold input as previously
  young domains were always marked suspicious regardless of their score
• Domains not returned by the API are now reported in the output message and JSON
  result so nothing silently goes missing
• BulkEnrichDomains now has a Merge With Case Entities option to combine a manual
  domain list with case entities in a single run
• Expanded the data enriched from the API, both bulk and risk enrichment actions
  now capture significantly more fields including expiration date,
  registrant/registrar details, hosting info, tracking codes, contacts, redirect
  info, and tags
• GetDomainProfile dates (create date, expiration date) now include the pivot
  count alongside the value
• Fixed suspicious flag not being cleared on re-run. If a domain previously
  scored above the threshold but drops below it, the flag is now removed instead of
  staying stuck
• Fixed GetWhoIsHistory checking the wrong API license

Description

Please provide a detailed description of your changes. This helps reviewers understand your work and its context.

What problem does this PR solve?
The DomainTools integration lacked three new enrichment actions (EnrichDomainRisk, BulkEnrichDomains, GetDomainProfile), had several bugs in the existing actions (wrong license check on GetWhoIsHistory, construct_csv imported from the wrong module, suspicious flag never cleared on re-run), and returned limited data from the API as it has missing fields like registrant details, hosting info, tracking codes, contacts, redirect info, and expiration dates.

How does this PR solve the problem?

• Adds three new actions using iris_enrich and iris_investigate API endpoints with
  full field mapping into typed datamodels
• Expands EnrichedDomainSummary and IrisInvestigateModel to capture the full API
  response including contacts, tracking codes, tags, hosting, and registration
  fields
• Fixes is_suspicious to be driven solely by the configurable Risk Threshold input
  and always re-evaluated on each run so stale flags are cleared
• Adds missing domain reporting across all three actions so domains not returned
  by the API are surfaced in the output instead of silently dropped
• Adds a Merge With Case Entities parameter to BulkEnrichDomains to support
  combining a manual domain list with in-scope case entities
• Fixes GetWhoIsHistory license check from parsed-domain-rdap to whois-history
• Fixes construct_csv import to use TIPCommon.transformation instead of the
  top-level TIPCommon package

Any other relevant information (e.g., design choices, tradeoffs, known issues):

• Removed widgets.

Checklist:

Please ensure you have completed the following items before submitting your PR.
This helps us review your contribution faster and more efficiently.

General Checks:

• I have read and followed the project's contributing.md guide.
• My code follows the project's coding style guidelines.
• I have performed a self-review of my own code.
• My changes do not introduce any new warnings.
• My changes pass all existing tests.
• I have added new tests where appropriate to cover my changes. (If applicable)
• I have updated the documentation where necessary (e.g., README, API docs). (If applicable)

Open-Source Specific Checks:

• My changes do not introduce any Personally Identifiable Information (PII) or sensitive customer data.
• My changes do not expose any internal-only code examples, configurations, or URLs.
• All code examples, comments, and messages are generic and suitable for a public repository.
• I understand that any internal context or sensitive details related to this work are handled separately in internal systems (Buganizer for Google team members).

For Google Team Members and Reviewers Only:

• I have included the Buganizer ID in the PR title or description (e.g., "Internal Buganizer ID: 123456789" or "Related Buganizer: go/buganizer/123456789").
• I have ensured that all internal discussions and PII related to this work remain in Buganizer.
• I have tagged the PR with one or more labels that reflect the pull request purpose.

Screenshots (If Applicable)

N/A

Further Comments / Questions

N/A